"any OQS repo" -- No. Suggest to agree on a subset. Ideally only those with a diverse, active contributor base which can play ball, err, handle problems (to stay in the picture, there should be more linebackers for that project than quarterbacks)

We haven't enabled vulnerability reporting on all OQS repositories. So really this can be turned into a point about only turning on security vulnerability reporting on repositories that we have a sufficient base to support.

What I meant (and probably should have clarified) was that we should make sure we're aware of all vulnerability reports, whichever repo they're filed on. For instance, if we have security advisories enabled for oqs-demos, it's possible we'll receive a report there that is pertinent to liboqs, even though (I imagine) we won't offer any sort of security policy for the demos.

Ah, now I get it. Honestly I wasn't aware that security advisories are enabled for all, even ancillary, sub projects... Out of curiosity: When was that decided and how does this fit to this statement

we won't offer any sort of security policy for the demos.

? I would agree to this statement, but then I don't understand this statement now:

it's possible we'll receive a report there that is pertinent to liboqs

AFAIK we didn't enable reporting security issues for demos, right? Just the publication of advisories (which is a weird combination, honestly).

I think this ties to #2 (comment): What is it that @dstebila labels "fully supported" ? Having a security policy and everything as per this conversation that goes with it?

Honestly I wasn't aware that security advisories are enabled for all, even ancillary, sub projects... Out of curiosity: When was that decided and how does this fit to this statement

Looking in the Settings tab on Github for oqs-demos, I don't see any option to enable/disable security advisories -- perhaps it's always enabled?

I think this ties to #2 (comment): What is it that @dstebila labels "fully supported" ? Having a security policy and everything as per this conversation that goes with it?

The criteria you stated at the top of #2 defined "Fully supported (at least 2 fully committed maintainers)" which is what I applied. If you want to add having a security policy to that, or other things, I'm open to that, but that probably belongs in the discussion on #2.

In the latest version, I have proposed limiting the scope of this document to liboqs, oqs-provider, and the language wrappers.

I'm not sure I'm happy with this as this basically puts two people as "single failure points" into the line of fire: @vsoftco and @baentsch . My proposal thus is to add oqs-provider and language wrappers to this list only after they have more than 1 achieved (read: regularly active, solving real problems, doing code, i.e., really able to resolve security issues), long-term committed contributor(s). Professionally, I'd argue for at least 3, but as long as we resolve open-quantum-safe/liboqs#2065 before this is merged, "more than 1" should do as the expectations would then be properly set.

For oqsprovider I could see @bhess as a possible candidate but wouldn't want to "volunteer" him to this commitment (to handle any and all oqsprovider security incidents within short notice). For language wrappers, the question goes to @vsoftco; What's your take? Who could alleviate you of the pressure to be the only person with "deep knowledge"? Or is this not as much a problem for you as it is for me (oqsprovider has a line count about an order of magnitude higher than any language wrapper and equally more integration (and hence, possible security failure) points).

How about refining the scope as follows:

1. The response process only applies to security issues with liboqs itself.
2. The VMT will triage reports received on provider or the language wrappers, but if a security issue is found to lie in provider or language wrapper "glue" code, then the report is considered "Out of scope."
3. Security releases and announcements for liboqs should still flow down to provider and the language wrappers via corresponding releases/announcements. The work for this should be minimal, and could be done by anybody on the VMT.

My rationale for (2) is that a reporter may file a liboqs-related security issue on provider or a language wrapper if that's where they observe the bug and they don't have the expertise to identify it as a liboqs issue.

That would be an OK approach for me and one pretty workable AFAIK for language wrappers: For those, I'd agree that there's a very low probability to find the root cause for security problems there. oqsprovider is a substantially different beast: I know that PQCA considers it a wrapper or "glue code" (to openssl) -- but while that used to be true at the beginning this is covering (way) less than half the story by now. Just look at all of the hybrid and composite logic that is true crypto code (creating and manipulating keys and other crypto material) or all the problems created by (standard algs') key material representation or all of the "data juggling" required to satisfy the OpenSSL APIs: As such oqsprovider certainly does contain security weaknesses "of its own" and thus will be subject to "original" security problem reports, i.e., ones not affecting liboqs or any upstream algorithm.

That said and thinking some more about it, I actually have the hunch that oqsprovider contains more code subject to security vulnerabilities than liboqs if discarding the "upstream" core algorithm logic from consideration and assuming a libcrypto (OQS_USE_OPENSSL) based build of liboqs. Created #138 as a possible way to move this "hunch" more towards "knowledge" (and address a pretty general weakness I see in OQS, code coverage testing). Thinking some more about it, I actually wonder whether resolution of #138 shouldn't be a prerequisite for this PR to land?

That would be an OK approach for me and one pretty workable AFAIK for language wrappers: For those, I'd agree that there's a very low probability to find the root cause for security problems there. oqsprovider is a substantially different beast: I know that PQCA considers it a wrapper or "glue code" (to openssl) -- but while that used to be true at the beginning this is covering (way) less than half the story by now. Just look at all of the hybrid and composite logic that is true crypto code (creating and manipulating keys and other crypto material) or all the problems created by (standard algs') key material representation or all of the "data juggling" required to satisfy the OpenSSL APIs: As such oqsprovider certainly does contain security weaknesses "of its own" and thus will be subject to "original" security problem reports, i.e., ones not affecting liboqs or any upstream algorithm.

That said and thinking some more about it, I actually have the hunch that oqsprovider contains more code subject to security vulnerabilities than liboqs if discarding the "upstream" core algorithm logic from consideration and assuming a libcrypto (OQS_USE_OPENSSL) based build of liboqs.

I agree with this assessment, and I think it's backed up by the distribution of security reports we've received (which I'll admit is a very small sample).

Created #138 as a possible way to move this "hunch" more towards "knowledge" (and address a pretty general weakness I see in OQS, code coverage testing). Thinking some more about it, I actually wonder whether resolution of #138 shouldn't be a prerequisite for this PR to land?

I don't think it's a prerequisite, but I have put up open-quantum-safe/liboqs#2072 as a first step toward resolving #138.

Are there other scenarios that would be considered out of scope? For instance, could a vulnerability outside the OQS threat model be classified as such?

Good point! I've expanded on "out of scope."

I know this report is closed and dealt with, but re-reading it makes me wonder: If liboqs is affected, wouldn't that imply that at least the language wrappers are also affected automatically? Also oqsprovider makes available HQC code if I'm not mistaken. So in case of a more severe problem with liboqs what would such problem mean for dependent OQS sub projects? Should that be spelled out somewhere?

I've fleshed out the main document to specify that oqs-provider and the language wrappers should also have advisories published whenever a liboqs advisory is published.

OK for me, if the understanding is that such advisories can/will be done by anyone in the VMT and not fall as responsibility to the committer/maintainers of the sub projects.

Refinement addressing this now suggested here: #124 (comment)

As a follow-up to my previous comment: Are all sub projects to be checked or are there some we don't consider (oqs-demos? ci-containers? profiling?). I'd guess that should also be spelled out ahead of time so the responsible committers and maintainers can agree on their involvement (level). And if indeed a vulnerability should be fixed "througout the OQS suite", all steps to do so should be clear -- either in writing for manual execution or as an automation/script.

As a follow-up to my previous comment: Are all sub projects to be checked or are there some we don't consider (oqs-demos? ci-containers? profiling?). I'd guess that should also be spelled out ahead of time so the responsible committers and maintainers can agree on their involvement (level). And if indeed a vulnerability should be fixed "througout the OQS suite", all steps to do so should be clear -- either in writing for manual execution or as an automation/script.

I've refined this in the latest version of the proposal. Input welcome :)

Good point. This calls for a script to do that, e.g., executing all CI commands locally (and for all sub projects deemed affected): TBD.

I'm not sure executing all CI commands locally is required, as all CI will run after merge to main (i.e., before release). I'm thinking about Windows / Intel macOS / etc jobs that may be difficult to execute without access to GitHub hardware. But, I agree that we should run as many as reasonably possible.

So what wording do you suggest @SWilson4 ?

My proposal is "The patch has to pass all CI tests in local execution including a new test demonstrating absence of the faulty behaviour fixed by the patch."